\chapter{Requerimientos}

\label{requerimiento}

\section{Introducci\'on}

	\subsection{Prop\'osito}

	El siguiente proyecto es desarrollado en el marco de la tesis de grado de la carrera Licenciatura en 			Ciencias de la Computaci\'on de la Facultad de Ciencias Exactas F\'isico-Qu\'imicas y Naturales de la 			Universidad Nacional de R\'io Cuarto denominada \textbf{\emph{Dise\~no e implementaci\'on de 					biyecci\'on para LAV (LibAntiVirals)}}, el mismo fue sugerido por FuDePAN.
	
	\subsection{Convenciones del Documento}
	Las palabras clave DEBE, NO DEBE, REQUERIDO, DEBER\'A, NO DEBER\'A, DEBER\'IA, NO DEBER\'IA, 	   	       	RECOMENDADO, PUEDE Y OPCIONAL en este documento son interpretadas como est\'a descripto en el documento RFC 2119.
	
	\subsection{Alcance del Trabajo}

	Este trabajo tiene como finalidad dise\~nar y construir un modulo que implemente una biyecci\'on 				entre el conjunto de mutantes posibles, y el conjunto de combinaciones de antivirales (es decir, 				\textit{$\mathcal{P}$(ARVs)} conjunto partes del conjunto de ARVs).
	La biyecci\'on puede definirse de la siguiente manera:
	\begin{itemize}
		\item[1.- ] Dado un elemento perteneciente al conjunto de mutantes del virus,												retorna	un elemento del conjunto $\mathcal{P}$(ARVs) que son aplicables a dicho virus.\\
		\item[2.- ] Dado un elemento perteneciente a $\mathcal{P}$(ARVs) que aplica a una mutante, retorna el 
		            conjunto de mutantes resultantes luego de dicha aplicaci\'on.\\
	\end{itemize} 
	
	Simb\'olicamente la biyecci\'on puede definirse como dos funciones, \textit{Aplicables} y 	
	\textit{Mutantes} de la siguiente forma:\\
	Sea M un conjunto de mutantes del virus y ARVs el conjunto de todos los Antirretrovirales.\\
	Definimos a $\mathcal{P}$(ARVs) como el conjunto partes de ARVs.\\
	Sea x $\in$ M y z $\in$ $\mathcal{P}$(ARVs), con z $\not=$ $\emptyset$.\\
	\begin{itemize}
		\item[1.-] $Aplicables(x) \to \{\mathcal{P}(ARVs)\}.$\\			
		\item[2.-] $Mutantes(x, z) \to \{M\}.$\\
	\end{itemize}
	
	\subsection{Estructura del Documento}
	La estructura de este cap\'itulo sigue las recomendaciones de \emph{Gu\'ia para la especificaci\'on de 			requerimientos de la
	IEEE (\href{http://standards.ieee.org/findstds/standard/830-1998.html}{IEEE Std 830-1998 }).}\\
	En la secci\'on \textit{Descripci\'on General} se da una perspectiva del producto a desarrollar y una 			explicaci\'on detallada de las funcionalidades a implementar.
	En la secci\'on \textit{Restricciones} se detallan los principales atributos que debe cumplir el 				software.
	
	
	\subsection{Abreviaturas y Glosario de t\'erminos}
	\label{Glosario}
	\begin{itemize}
	    \item[*] FuDePAN: Fundaci\'on para el Desarrollo de la Programaci\'on en \'Acidos Nucleicos.
	    \item[*] VIH: Virus de la inmunodeficiencia humana.
		\item[*] biLAV: Biyecci\'on para LAV. Nombre otorgado a este proyecto.
		\item[*] LAV: Librer\'ia de AntiVirales.
		\item[*] ASO: Optimizador de Secuencias de Antivirales.
		\item[*] SAARNA: An\'alisis est\'atico de Antirretrovirales y RNA.
		\item[*] ViSi: Simulador de virus.
		\item[*] ARVs: Antirretrovirales. F\'armacos para el tratamiento por la infecci\'on del retrovirus 
				del VIH.
		\item[*]$\mathcal{P}$(ARVs): Conjunto parte del conjunto de ARVs.
		\item[*]Mutante: Secuencia del virus resultante luego de aplicar un conjunto de ARVs a una 
		                 secuencia inicial de virus.
		\item[*]Poblaciones Mutantes: Conjunto de identificadores de mutantes.
	\end{itemize}
	
\pagebreak{}


\section{Descripci\'on General}

	\subsection{Perspectiva del Producto}
	El producto a desarrollar permitir\'a agregar nuevas funcionalidades a las ya existentes en la   
	librer\'ia \textit{LAV}. De esta manera los distintos proyectos que la fundaci\'on posee y que utilizan 
	dicha librer\'ia (especialmente \textit{ASO}\footnote{aso.googlecode.com}, 						
	\textit{SAARNA}\footnote{saarna.googlecode.com} y \textit{ViSi}\footnote{visi.googlecode.com}), podr\'an 		
	realizar un pasaje entre antivirales y secuencias del virus de manera eficiente.
	
	\subsection{Requerimientos Funcionales del Producto}
	\label{RF}
	En esta secci\'on se detallan los Requerimientos Funcionales espec\'ificos que resultaron del An\'alisis 
	documentado en el siguiente cap\'itulo.
	\begin{itemize}
		\item \textbf{RF1}: El m\'odulo DEBER\'A calcular el tama\~no del conjunto de mutantes con el 								 cual va trabajar.
		\item \textbf{RF2}: Dado un identificador del virus, el m\'odulo DEBER\'A retornar la mutante a 								la que hace referencia dicho identificador.
		\item \textbf{RF3}: Dada una mutante, el m\'odulo DEBER\'A retornar su identificador.
		\item \textbf{RF4}: El m\'odulo DEBER\'A calcular a partir de un identificador, el conjunto de 								antivirales a los cuales es sensible el virus que representa dicho identificador.
		\item \textbf{RF5}: El m\'odulo DEBER\'A calcular a partir de un elemento de $\mathcal{P}$(ARVs) que aplique 
		                  a una secuencia del virus, el conjunto de identificadores (que representan a las mutantes) 
		                  que resultan luego de dicha aplicaci\'on.
		\item \textbf{RF6}: El m\'odulo DEBER\'A calcular a partir de poblaciones mutantes, la 
		                    intersecci\'on entre	los conjuntos de antivirales que aplican a cada poblaci\'on.
		\item \textbf{RF7}: El m\'odulo DEBER\'A calcular a partir de un elemento de $\mathcal{P}$(ARVs) que aplique 
		                    a poblaciones mutantes, la uni\'on de todas las mutantes resultantes de 
		                    dicha aplicaci\'on.
		\item \textbf{RF8}: El m\'odulo DEBER\'A calcular a partir de un identificador del virus, el conjunto de identificadores (que representan a las mutantes) alcanzables\footnote{Dado un identificador \textit{id} (que representa a una mutante) se define a todos los identificadores alcanzables desde \textit{id}: al conjunto de identificadores que resulten de la aplicaci\'on de un conjunto de ARVs a (id) y a todos los nuevos identificadores resultantes de dicha aplicaci\'on} desde dicho identificador.
	\end{itemize}
	
\section{Restricciones}
	El producto DEBE ser desarrollado utilizando el lenguaje de programaci\'on C++ y bajo la licencia de   		
	software GPLv3.
	
	\subsection{Suposiciones y Dependencias}
	Sistema operativo: GNU/Linux.
	
	\subsection{Restricciones de Dise\~no}
	El producto DEBER\'A cumplir con los siguientes principios de dise\~no de
	la programaci\'on orientada a objetos\cite{DesignPrinciples}.
	\label{solid}
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)\cite{DOO} es un acr\'onimo memot\'ecnico introducido por Robert C. Martin a comienzos del 2000 el cual se basa en 5 patrones b\'asicos de dise\~no y programaci\'on orientada a objetos.\\
Cuando los principios se aplican conjuntamente propician el mantenimiento y extenci\'on del mismo en el tiempo.
\begin{itemize}
\item \textbf{Principio de Simple Responsabilidad (SRP)}: En la Programaci\'on Orientada a Ojetos, el
			Principio de Simple Responsabilidad, establece que, cada objeto debe tener una \'unica 							responsabilidad, y que la responsabilidad debe ser completamente encapsulado por la clase. Todos 			sus servicios deben estar estrechamente alineados con esa responsabilidad.
\item \textbf{Principio de Apertura/Cierre (OCP)}: El principio de apertura/cierre establece que entidades 					de software (clases, m\'odulos, funciones, etc) debe quedar abierto a la extensi\'on, pero 						cerrado para su modificaci\'on, es decir, una entidad puede permitir que su comportamiento pueda ser modificado sin alterar por completo su c\'odigo fuente.
\item \textbf{Principio de sustituci\'on de Liskov (LSP)}: El principio de sustituci\'on de Liskov es una
			definici\'on particular de una relaci\'on de subtipificaci\'on, llamado subtipificaci\'on de 					comportamiento, que fue introducido inicialmente por Barbara Liskov\footnote{http://www.pmg.csail.mit.edu/~liskov/}. Establece que ``los tipos	derivados deben poder ser sustitutos completos de sus tipos base''.
\item \textbf{Principio de Segregaci\'on de Interfaz (ISP)}: El principio de Segregaci\'on de Interfaz dice
			que una vez que una interfaz se ha puesto demasiado ``grande'' tiene que ser dividida en partes 					m\'as peque\~nas y m\'as interfaces espec\'ificas para que cualquier cliente de la interfaz 					pueda s\'olo saber acerca de los m\'etodos que les pertenecen. En pocas palabras, ning\'un 						cliente deber ser obligado a depender de m\'etodos que no utiliza.
\item \textbf{Principio de Inversi\'on de Dependencia (DIP)}: El principio de inversi\'on de dependencia
			promueve que hay que depender de abstracciones, no de concreciones. Dicho de otra forma, los
			m\'odulos de m\'as alto nivel no deben depender de los de m\'as bajo nivel sino que ambos deben
            depender de abstracciones. Y a su vez, las abstracciones no deben depender de los detalles sino   			al contrario.
\end{itemize}

\subsection{Atributos del Software}
	El producto DEBER\'A:
	\begin{itemize}
		\item[*] Compilar sin advertencias, o las advertencias aceptadas DEBER\'AN estar documentadas.
		\item[*] Cumplir con el est\'andar ANSI C++\footnote{http://es.wikipedia.org/wiki/ANSI\_C} y el ``coding style'' definido por FuDePAN.
	\end{itemize}

	El software DEBER\'A:
	\begin{itemize}
		\item[*] Funcionar sin memory leaks\footnote{Los memory leaks ocurren cuando un bloque de memoria reservada no es liberada correctamente.}.
		\item[*] Tener al menos un 85\% de cobertura con pruebas automatizadas\footnote{En esta tesis se utiliz\'o Google Test para automatizar los test.} (ver Cap\'itulo \ref{Pruebas}).

	\end{itemize}
	
\section{Requerimientos profesionales}
\begin{itemize}
 	\item[*] Aprobar el Programa de Entrenamientos para Voluntarios (PEV) de FuDePAN.
 	\item[*] Charla de Bioinform\'atica dictada por FuDePAN.
 	\item[*] Conocimientos en Test automatizados (Google Test).
\end{itemize}
\newpage
\vfill

